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SYSTEM MANAGEMENT METHOD AND number of different expert systems (Consultants); however, 

APPARATUS unlike the ANM system in which the Experts are concerned 

TKVPNxrr. W wth respective types of network problem, in the Hewlert- 

HELD OF THE INVENTION Pochard apparatus each Consultant is concerned with a 

The present invention relates to a system management . 5 f^ 001 ^ one of me types of operations normally involved 
method and apparatus for carrying out at least one manage- m thc ^y 5 * 3 of any given network problem, 
ment task in relation to at least one service intended to be 10 t** 61 thcsc ktter arrangements, expert knowledge is 
provided by a computer system In particular, but not encoded in expert systems with the object of identifying 
exclusively, the present invention relates to a method and network faults given a set of symptoms and suggesting 
apparatus for facilitating the carrying out of a number of 10 po^Mc solutions. Any knowledge about what should be 
management tasks (such as installation, monitoring, and happening on the system is closely bound to the problem to 
fault diagnosis) in relation to a number of different services ! °l v *d- As a result, the expert knowledge is not available 
(such as log-on, electronic mail, and print spooling) pro- ^ OT usc m omcr types of management task where no fault 
vided on a network of computers- exists, such as installation of a service. This trait is charac- 

15 teristic of today's systems that seek to provide assistance in 
BACKGROUND ART toe carrying out of network management tasks and one 

Over recent years the complexity of computer systems wn f«J ue «* of this has been that each management task 
(and in particular, computer networks) has increased t0 h * v< ; 1 *™ D special mds (generally in the form of 

considerably, such systems being characterised by the inter- ™ softw * re *e number of which for each task corre- 
action of multiple system entities in providing a variety of sponos ^ wc number of network services in respect of 
different services. One result of this is to have placed a whldl we task is to be effected. 

considerable strain on system management resources tasked fi is ^j"* of mc present invention to facilitate system 
to keep such systems up and running. Whilst low-level management by providing expert knowledge about the sys- 
fault-diagnosls equipment such as protocol analyzers have ^ tcm m a more useful form. 
evolved generally in line with the increasing sophistication ™ n mT mv np -r™ TrjvTwrrnw 

of the technologies used for inter-linking system entities, DISCLOSURE OF THE INVENTION 

such equipment has often tended only to serve as an aid to h general terms, the present invention achieves this 
a maintenance engineer, telling him/her what is wrong at the object by specifying (he requirements needed for a particular 
particular point under test Similarly, higher-level network x service to be available in the form of a declarative model and 
management systems that seek to provide an overview of ^en defining management tasks in terms of general infer- 
overall system performance by collecting data from all parts encing operations that can be carried out on such models. As 
of a network, have largely been of limited use leaving much a consequence, each service model can be used by each task, 
of the problem of understanding what is going on to the As used herein, the term "declarative model" refers to an 
network supervisor. M abstract description of a service, the Tn«mfng of the model 

More recently, a number of proposals have been made to being independent of any form of processing to which the 
introduce expert system technology to network fault diag- model may be subject; a model thus has no notion of 
no sis and management. One network management system sequence, iteration or choice in relation to how it is to be 
using such technology is the ANM (Automated Network used (in contrast to what is typically the case with imperative 
Management) system described in the article "ANM: Auto- 40 models) and, instead, the model employs logical operators 
mated Network Management System" by Feridun, M Lcib, ( sucn ^ AND, OR ,NOT) and recursion as appropriate. Of 
M Nodine and J Ong, IEEE Network, March 1988— Vol 2, course, concepts of sequence, iteration and choice may well 
No 2. In the ANM system, network entities such as be represented in the model as part of the modelling of the 
gateways, provide data to a backbone of Distributed Man- service concerned but this does not affect the declarative 
agement Modules (DMMs) which service 'Clients ' that 45 naturc of the model. 

provide the network management services. Clients request It should be noted that the type of model here referred to 
and receive raw data collected from network entities by the is fundamentally different from that disclosed in Interna- 
DMM backbone; Clients can also request the DMM back- tional Application WO 92/05485 (Cabletron Systems) where 
bone to execute specific actions. A specialised Client called a 'virtual network* simulating a real network being 
an Intelligent Network Manager is provided and comprises 50 managed, is built up from 'models' of each entity in the real 
a collection of expert systems (Experts) organised as a network. Neither the 'virtual network' nox the individual 
top-level Expert which forwards triggering data received 'models' of the Cabletron system seek to describe a network 
from the network entities to other Experts that each under- services as is the case in the present invention; furthermore, 
stand a specific kind of network problem. These Experts, in thc Cabletron 'models' have a one-to-one correspondence 
turn, may suggest possible hypotheses that might explain the 55 with real world items which again differs from the present 
triggering data. If necessary, each Expert may request addi- invention where a single service model defines the require- 
tional data from network entities. When Experts suggest, ments of a service regardless of whether there are none, one 
confirm or reject hypotheses, the network operator is or many actual instances of the service in the real system, 
informed. To add expertise about a new type of network More formally stated, according to one aspect of the 
problem, to the Intelligent Network Manager of ANM, a « present invention, there is provided a system management 
new Expert must be added to the system, and to change the method for carrying out at least one management task in 
way the system reasons about problems, all Experts con- relation to at least one service intended to be provided by a 
ducting such reasoning must be changed, computer system made up of cooperating physical and 

Another example of the use of expert system technology logical entities, the method comprising the steps of: 
in the field is the network monitoring and analysis apparatus es providing for the or each said at least one service, a 
described in European Patent Application 0 473 255 A2 respective declarative model specifying independently 

(Hewlett-Packard). This apparatus is also provided with a of any particular said task, the requirements needing to 
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be met for the service to be available, these require- desired information (In this latter case, the desired 

meats being set out in terms of the entities required and information is ascertained either directly through quc- 

their inter-reiatiooships, ries designed to elicit specific items of information, or 

providing for the or each said at least one management indirectly by inferencing from the results of a particular 

task, respective tailr control means for controlling 3 system function exercised by the interaction), 

performance of the corresponding task in a manner The system management method is applicable not only to 

independent of any particular said model and in terms tasks where the computer system is left unaltered by the task 

of general inferencing operations that can be performed (fo r example, a fault diagnosis task), but also to tasks (such 

on any said model, and as installation of a service far a particular user) that require 

performing a said at least one management task in relation 10 the system to be changed in some manner (by adding or 

to a said at least one service by a process involving removing an entity or by modifying the inter-relarionship 

effecting inferencing operations oh the corresponding between at least two entities). 

declarative model under the control of the said task According to another aspect of the present invention, 

control means relevant to that management task. there is provided system Tnanagemr.nt apparatus for carrying 

Preferably, each said task control means comprises a 15 out at least one management task in relation to at least one 

respective task program for controlling the operation of an service intended to be provided by a computer system made 

inference engine to perform the corresponding task, the up of cooperating physical and logical entities, the apparatus 

same engine being used for each task regardless of the model comprising: 

to be processed. However, it is also possible to arrange for for the or each said at least one service, a declarative 
a said task control means to be embodied in the functional 20 model specifying independently of any particular task, 
architecture of an inference engine thereby specifically the requirements needing to be met for the service to be 
adapting that engine for the corresponding task; in this case, available, these requirements being set out in terms of 
there will be a respective inference engine for each task to the entities required and their mter-relationships, 
be performed. An intermediate approach is also possible irfaence engine means for carrying out inferencing 
where the functional architecture of a common inference 25 operations in relation to a said declarative model, 
engine is determined by the task to be P^T^^ for the or each said at least one management task, 
addition, there is a task program CT emsmg trus functionamy respecdvc task for controlling perfor- 
in a programmed manner; tins approach is feasible due to the ^pecttve sa idlfWnce 
fact that inference engines are generaUy cngilic ^ „ a nXcrhdependent of any particu- 
software routmes on standard hardware so^t the^on 30 ^ model and in texrnTof general inferencing 
ality of the inference engine can be changed by altering the . . 

inter-relationship of its component routines. °P er 0QS * a . 

The system management method of the invention is means for causing a management task to be earned out in 

particularly advantageous where there are multiple services relation to a particular service by causing said inference 

and multiple tasks to be performed as it avoids the need to 35 engine means to operate on toe corresponding declara- 

write special programs to carry out each pairing of service tive model under the control of fee task control means 

and task However, the method is also applicable where relevant to that management task, 

there is only one service provided or only one task to be Preferably, the system management apparatus further 

performed, comprises fact base means for storing facts about the system, 

GeneraUy, the computer system to be managed (typically « and interaction means for interacting with the system to 

a computer network) will be capable of supporting a plu- ascertain either directly or through Ltfereaang from the 

raHtyof instantiations of a service, the step of carrying out results of the Interaction, facts about the system, the infer- 

a management task in relation to that service involving ence engine means being operative in the course of carrying 

identifying an instantiation of the service and then using the out a said management task to check whether a said rcquire- 
appropriate service model to inference information in rela- 45 ment is being met by the system by referring to the fact base 

tion tothe identified service instantiation. ™*™ and in the event that insufficient facts are present in 

Advantageously, the declarative model of a service com- the fact base means, by causing the interaction means to 

prises a hierarchical structure of declarative statements interact with the system to elicit further facts, 

inter-relating entities, statements lower in the hierarchy BRIEF DESCRIPTION OF THE DRAWINGS 

serving to detail requirements specified by statements higher so S3I ^ r 

in said hierarchy. System management apparatus embodying the present 

These statements may include, in addition to statements invention will now be described, by way of non-limiting 

directly specifying requirements, statements generally inter- example with reference to the accompanying diagra mmati c 

relating entities and usable to infer whether a particular drawings, in which: 

requirement has been met Where appropriate, a model can 33 pjQ 1 [ s a depiction of a computer system as seen from 

be associated with another such that statements set out in one ^ perspective 0 f an eQ d user; 

model and involving a particular entity, are usable in the depictioo of a computer system as seen from 

other model in connection with the same entity J of ^system ZSgeV. 

The reauirements specified in a service model can advan- mo ^ ^ ^ » * 

i^TSuo sets, oamely a set of essential . TO - 3 * M ^™^. of *'^^^^ 

Seal requirements and a tatter set of operating policy apparatus en*odylng the invention showing the aay-Kwuiy 

reauiremJ S emn g <»t,for«an>pte.naniestobeo S «ifor patog of task programs and servce models; 

particular files. P 10 - 4 a a (ii m am of an inference engine of the FIG. 3 

Advantageously, to facilitate the carrying out of a man- apparatus; 
agement task, information on the system is made avail- . 65 FIG. 5 is a search tree illustrating operation of the FIG. 4 

able through reference to a fact base which can be inference engine in respect of an example service model, 

updated through interaction with the system to provide when given a set of predetermined facts; 
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FIG. 6 is a search tree illustrating operation of the FIG. 4 concerned may be obtained by inter-action with the cora- 

lnfcrcnce engine in respect of the same service model as for puter system. Actions detail how to initiate the carrying out 

FIG. 5, but where queries are used to elicit facts; of procedures relevant to the modelled service that may be 

FIG. 7 is a diagram illustrating the format of a service required to implement certain tasks, 
model including the definition of three entity types with 5 The management system 20 comprises an inference 

associated relations; engine 25, a fact base 26 and an inter-action manager 27. 

FIG. 8 is a diagram illustrating inheritance between ^"IfT^ oat any particular task undo the control of 

service-model cmtitieT and importation ac^rn^T one of mc^ programs 21 , the inference engine 25 uses the 

Prr 0 ic - h »«. T*™ across mooeis scmce fQf ^ scxvicc m ^ whicfa me ^ ^ 

FIG. 9 is a diagram of the functions involved in providing being carried out, to identify the requirements for the service 

a print spooler service to a network user; and then uses whatever information might be available to it, 

FIG. 10 is a drawing of how the FIG. 9 service can be to make certain inferences from these requirements (in 

expressed in terms of service models and entities; particular, whether they have been met or need to be met): 

FIG. 11 is a diagram illustrating the format of a query The fact base 26 stores facts already known to the manage- 
usable to obtain information from the computer system 15 mcnt system and which are therefore directly available to the 

being managed; and inferencing engine 25. If desired facts are not in the fact base 

FIG. 12 is a drawing of syntactic parsing of a return string ^ mc Mcrcnoe 25 is operative to use the queries 

giving information about a user of the computer system associated with the relevant service model 22 to cause the 

being managed. inter-acton manager 27 to interact with the computer system 

20 wi* 11 a view to obtaining the facts concerned directly or 

BEST MODE FOR CARRYING OUT THE indirectly through experience. Furthermore, if it is necessary 

INVENTION to modify the system being managed in order to complete a 

task (for example, installation or removal of a service), the 

OVERVIEW inference engine is operative to cause appropriate predefined 

prr, i « on ~r ♦ .* 25 actions associated with the relevant service model 22 to be 

^ }f^^^^^^^^^^P^m 25 initiated via the interactions manager 27. 

work stations 10 and peripheral devices 11 (for example, . •„ ~7T ^ . 

printers) inter^onnectedvia a network includiDg LAxTg u?lZ l i . mstT ^ a """W * I»« *> natural 

ments 12 linked via bridges 13. FIG. 1 is a depiction of L SlV^if^T^ * ?T "Jl IT *** 

end-user's view of the system. An end-user 14 working at a „^ ™L ^ T"* , ^ t0 ** 

work station 10 wants L system to provide h«/him with 30 * f ° m , 

one or more services 15 such as logging into the computer Lo&a scmcc 15 far Ending user called Name, IF: 

system, running a particular application program, print me s y stem nas a «cord of a user by this Name, and 

spooling, electronic mail, and log off. this user has a password, and 

FIG. 2 is a depiction of for the same computer system as this user has a home directory, and 

FIG. 1 a the view of the system taken by a system manager *** USCT ^as execute access to that directory. 

16 also working at a work station 10 of the system. For each now v^^cd to carry out diagnosis of the login 

service available to an end user on the system, the system strvice for a particular user, a diagnosis task program causes 

manager 16 must be ready to carry out a number of tasks 17 ^ 6 infcrcnce engine 25 to examine the login service model 

including installation of the service, configuration of the ^ ^ identit y 811 me requirements mat must be met For 

service, fault diagnosis, fault fixing and removal of the example, if a user called "John" cannot login, then the model 

service. To this end, the system manager's work station runs statcs mat me svstcm ^st know about a user with that 

appropriate software that turns the weak station into a aame, that he must have a password, that he must have a 

management system for carrying out each task in relation to home directory, that he must have execute access to that 

each service. In prior art systems, this management system 45 dircctor y ; the inference engine 25 proceeds under trie control 

has required the writing of specific programs for each of tnc diagaosis **** program to ascertain which of these 

pairing of service and task. The management system to be requirements has not been met 

described hereinafter and which embodies the present inven- Should it be desired to add a new user to the system, an 

tion obviates this need and requires only the characterisation "add-user" task program causes the inference engine 25 to 

of each task and of each service separately. examine the login service model to identify what require- 

The general form of the system management apparatus " ™ st te metfor the new user to be able to login; these 

embodied in the present invention is shown in FIG. 3. The rc ^L emcnts can then be met by appropriate actions on the 

main components of the apparatus are a set of task programs ^2?^ . 

21 (one for each of the m tasks to be performed), a set of P^f 1 ™ 5 ' "i™ 05 . <P^<* and actions 
service models 22 (one for each of n services provided by 5J * in a high-level language and 
the computer system), and a management system 20 con- COmpikd to ^ fcT cxecutioiL 
stituted by work station 10 of the computer system and INFERENCE ENGINE 
appropriate software. The general form of the inference engine 25 is illustrated 
Each service model 22 is a declarative model cf the in Ha 4. Conceptually, the Inference engine comprises a 
service concerned and specifies the requirements needing to « task control layer 30 for controlling the inference engine in 
be met for the service to be available. These requirements . accordance with the task program 21 supplied to it; a proof 
are set out in terms of relationships between the physical and system made up of a verifier 31, a knowledge assimilator 32 
logical entities of the computer system. A service model and a theorem prover 33; and a logic support layer 
contains no information about how it is to be used for (providing for unification, predicates and variables) pro- 
different management tasks. Associated with each service 65 vided by an appropriate language such as Prolog or Small- 
model are queries and actions 28. Queries detail how infer- talk both of which are well known to persons skilled in the 
marion regarding the requirements specified for the service art 
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With regard to the proof system, the verifier 31 uses a model 22 providing two queries Ql and Q2; query Ql is 

closed world deduction system far which if something 'goodfar' (that is, will give the value of) D and B and Q2 is 

cannot be proved true it is assumed to be false; the verifier ' goodfar 1 EG and H. In this case, the proof proceeds as 

does not utilise queries. The verifier 31 is thus useful for follows (see FIG. 6): 

discovering what can be true given the current state of 5 (l) The proof of A begins as before until the partial 

knowledge. The knowledge assimilator 32 uses a form of solution node DJEJ 7 is reached. This time there is no fact for 

abduction in order to find consistent extensions to the fact rj but there is a query Ql. So, query Ql is executed and this 

base that are sufficient to explain observations arising from puts mc f acts is true* and 'F is false' into the fact base, 

the results of queries. The main theorem prover 33 is an open enabling the next partial solution node to be created, 

world deduction system mat also considers queries; it is the 1Q ^) Now consider E,F. There is now a fact for E in the fact 

core of the inference engine. The role of the task control 30 base; ^ f ^ (£ is fals e) causes this branch to fail, 

is to integrate the operation of the elements of the proof (3) Bactoddng to mc ncxt U n<xpanded partial solution 

system in a manner to produce the results desired for the task Dodc ((hat ^ q mc scarcn i 3 continued as before, 

being effected; generally, however, it may be said that if the (4) whcQ Q ^ considered, there is no fact for it, but there 

theorem prover 33 is unable to prove a particular theorem on 13 ha quay q^. When this is executed the facts T is true', 'G 

the basis of facts currently available in the fact base, it wffl ^ ^ Jujd < H ^ false> m added to mc tict base which 

ask the verifier 31 to look at the queries to find one which resuUa m fl 

will provide it with the facts desired, and then once its query ^ sclection of ±t appropriate query and the extraction 

has been performed, the knowledge assimilator will extract of M(nmatio]) ^ result of a query involve the verifier 

as much information as possible from the results of the query ^ 3J and j^^^ge assimilator 32. 

and store this new information in the fact base for use by the ^ coursCj ^ foregoing examples are very simple but 

theorem prover 33. serve ^ illustrate the general operation of the inference 

A simple example of how the theorem prover 33 carries engine 25 in relation to the models 22, queries 23 and fact 

out reasoning on the basis of the rules given it in a service base 25. 

model 22 and having regard to facts available in the fact base ^ 

26, will now be given. SERVICE MODELS 

Each service model contains s^'""^^ A service model specifies a service provided by the 
entity or entities relevant to that model and these statements m terms of system entities associated with the 
will generally be used to forma nutnber of nd«££>£<£ ^ ^ ^ relatio * these entities, 
relationships) specifying, for example, that a service entity 30 . L . , . _ . , 
I a^blftf Suu^dMoK^c met Thus with refer- * Entities are items about which facts can be asserted and 
ence to the service model 22 of FIG. 4, there may be truth may correspond to logical objects such as integers, files, 
Xed srate^Tts A-H in the service model organized into operating modes, etc or to real-worW physical objects such 
three rul as machines, printers etc. A number of primitive or core 
. f J*' r entity types are conveniently pre-defined such as integers, 
A 11 u or c 33 ctaractcrs ^ stings and are implicitly available for use in 
B if D and E and F ^ service model Higher level entity types are then defined 
CifGorH ..inan appropriate service model with the characteristics of 
Statement A may represent that the service concerned is ^ such CQtity ^ b(ing specified in terms of relations 
available if statement B or statement C is true. The second ^tweca ,^^0^ and/or previously-defined higher-level 
rule given above then sets out the conditions to be fulfilled 40 tn ^ t& Each entitv ^ md its associated characterising 
for statement B to be true whilst the third rule gives the relations ^ hercm generally referred to as an Entity- 
conditions for statement C to be true. Relations group (or 'ER group' for short). 

By way of example, colder first tiie Relations may be basic, unconditional, relations between 

factbasecontainsmefactsthataFa > conditional, relations that are only true if 

main theorem prover 33 am now deduce whether or not the o ^ 
service represented by model 22 is ^ff-** ArXion itotmcs at least one entity and names a particular 

whether A is true. This prove proceeds as follows (See FIG. rdfldoQ the entities in a relation wfll be 

^ : . - „ specified in terms of variables of a specific entity type, the 

(1) Since there is no fact for A but there is a rule, the *> ^£ ^und when the%erti« model iTused 
search for a solution expands into two part^ soluuon codes iMercncVcngine; however, specific entity instances 

(2) Now consider B. Again there is no fact, but there is a J**^ ^ ^ a r ^ Q (such 7 U a name 
relevant rule so the search is again expanded. constituting fl particular string entity). 

(3) Now consider D3^There is a fact for D, so the next a^^itmaybe useM to specify whether 

^) Now "nSd^- is known to be false, so this 

more than one instance of another entity m the same relation, 
© teteUng to the next un-expanded partial solution this characteristic of the relation being termed its "cardinal- 
node (tbSE, Q there is no fact forC, but mere is a rule, For example, one directory can contain many files bu 

"T v ' . . 4 , m each file can be in only one directory and it may be useful 

"m^SSST™* is known to be true, so a to specify this property in any rdations associating files and 
solution has been found. directories. 

Note this example is just a simple depth-first search over A straightforward model win, for example, comprise an 
the solution space. Other scarch strategies are, of course, entity corresponding to the service itself and an associated 
also possible such as a "best first" strategy. 65 derived relation to the effect that the service entity is OK 

Consider next the sitaation where there are no facts in the (that is, functional) provided a set of conditions arc met, 
fact base 26. However, a set of queries is associated with the these conditions being particular relations between entities 
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involved in providing the service. The relations associated conditions 66,67 requiring to be met for a given file to be 

with these latter entities permit a determination to be made owned by a given user, namely that the file owner id should 

as to whether the conditions have been met for the service correspond to the user's user id, II should be noted that this 

entity to be 'OK*. correspondence is specified by use of an integer variable 
FIG. 7 illustrates, by way of example, a simple service 5 'nid* that will have a value bound to it when during 

model SO for a notional service for deleting a file. This application of relation 63, the inference engine in seeking to 

example model is considerably simplified over what might prove conjunction of the statements forming the conditions 

be expected in practice and is given purely to assist in 66, 67 finds a relevant fact giving the owner id of a file, and 

demonstrating the concepts involved in service models; applies this to condition 66; the value of 'idd* is now bound 
furthermore, the cardinalities of the relations involved have 10 and condition 67 can be tested. 

been omitted for simplicity. The convention used in this It win be appreciated that the variables specified in the 

specification is that entity types arc given initial capitals relations included in a service model will have values 

whilst corresponding variables start with lower case letters assigned to them either explicitly on initiation of a task (for 

and have generally similar names to their entity type; in fact, example, by the system manager) or by reference to the fact 
the type of a variable is declared at the first occurrence of the is base, or by use of the query system, 

variable except where me variable type is readily apparent in more sophisticated models, where a number of closely 

WitruiiareUtio^entitiesCwhetherrepresentedbya variable . related services exist such as a set of services provided by 

« specified as particular instances) are enclosed in square the same system object (for example, a file system manager) 

brackets and where the value of an entity does not matter then rather than having a^eparate entity for each such 
(only that U has one) the underscore symbol \_* is included *> service, it is convenient to define a general service entity 

in the brackets. The logical operators AND, OR and NOT conceptually spanning all the related services (this entity 

are represented by , ; and - respectively. could be thought of as equating to the relevant service 

The FIG. 7 service model 50 comprises a header 51 provider object of the system). This general service entity is 

identifying the model and three ER groups 52, 53, 54 then associated with each specific service through a corre- 
definmg three entity types, namely: 25 spending relation (normally a derived relation setting out the 

Delete_JUe — representing flic service itself; conditions for the specific service concerned to be 

User — representing users known to the system; available). Thus, with reference to the foregoing example of 

FUe— representing files on the system. a scryice for deleting a file, a general service entity type 

String and integer core entities are also used, 30 '^^^T? be defined to encompass all file-related 

m, ~, • ~ ... . . , - . J ^ . . services. The file deletion service then takes the farm of a 

The service entity Delete_file is declared m definition 55 derived relation- 
of ER group 52. Associated with the definition 55 are two 

relations, namely: — 

a derived relation 56 that sets out the conditions 57 to 59 lfik_jovioe] deieto_ffle_jbi [User uau] on [Fife file] bok n?: 

needing to be met if an instance of the service (represented 33 [file] U-owncdJ* [userl 

by variable 4 delete_Jile') is. to be OK for a given user 

(represented by variable 'user') in respect of a given file 

(represented by variable 'file*). The variables *user* and This can be interpreted as saying that the instance of the 

*file* arc of type User and File respectively and are specifi- File_service entity type represented by the variable ,l file_ 

cally declared as such. 40 service", can provide the file deletion service for the user 

a basic relation 60 giving the charging rate for the service represented by the variable "user", in respect of the file 

(here specified by the string 'FREE'). represented by the variable "file", provided the conditions 

It will be noted that the second relation 60 is not used in specified after "IF" are met 
detennining the functional status of the service but asserts a Two repetition-reducing mechanisms are preferably pro- 
relation that may be useful for other purposes. 45 vided to prevent undue repetition of the definition of entity 

The essence of relation 56 is that the file deletion service typcs and relations that may otherwise occur in modelling 

is available to a user represented by the variable 'user* in suostantiai service. These mechanisms are: 

respect of a file represented by the variable 'file' if the user INHERITANCE between entity types so that one entity 

owns the file (condition 57), no-one else is using the file x can inherit the relations of another, and 

(condition 58) and the legal status of the file is explicitly IMPORTATION enabling one model to make reference to 

'non retention*. It will be appreciated that when the condi- entities in another model 

tions are applied, the same values are bound to correspond- These mechanisms will be considered further below with 

ing variables in the various conditions, these values being reference to FIG. 8. 

those already bound to the variables in the first line of the « rrtn s Hfe«« m » M ».v..ii« a e , , ~ 

a-,, 55 rlu- 8 ^grammatically depicts four models 70 named 

derived relation 5* M1) ^ ^ M4 respectivcly< Mo(lcl M1 h shown as 

ER group 53 defines entity type User and has one basic including six ER groups 71 respectively relating to entity 

relation 61 specifying that each user (as represented by types named El to E6. Model M2 is shown with one ER 

vanahle 4 user') has a user identity that takes the form of an group 71 for an entity type named E7; model M3 is shown 

mtc ^- 60 in two ER groups 71 for an entity type named EIP. The 

ER group 54 defines entity type File and has three basic relations characterising each entity type are not explicitly 

relations 62, 64, 66 and one derived relatiOD 63. Relations depicted. 

62, 64, 65 respectively attribute to a file (represented by As already described with reference to FIG. 7 a relation 

variable file' ), an integer for identifying the file owner, an in one ER group of a mode! may refer to an entity of a type 

integer far specifying the current number of users of the file 65 defined in the same model. The reference to an entity ofa 

other than its owner, and a string for specifying the legal first type from within a relation of an ER group associated 

retention status of the file. Relation 63 sets out the two with a second entity type is herein referred to as "RUT 
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reference (derived from "Reference In Relation**). FIG. 8 
illustrates an RIR reference from a relation of the ER group 
associated with entity type El to an entity of type E2, this 
reference being depicted by an arrow. 

Entity types within the same model may also be related by 3 
an "ISA" reference mat specifies as inheritance relationship 
between two entities whereby the relations associated with 
one entity are inherited by another. If an entity inherits 
relations associated with another entity, this is declared in 
me definition of the entity type of the former, typically by an 10 
"ISA" statement. An ISA relation is illustrated in FIG. 8 
between the entity types E4 and B3 of model ML The 
inheriting entity is referred to as the "sub-entity" and the 
entity whose relations are inherited, is called the "super- 
entity". Inheritance may occur over several levels, building 15 
up a hierarchy of inheritance. 

In most practical systems, multiple service models will be 
denned and it becomes useful to be able to make RIR and 
ISA references that extend across model boundaries thereby 
to avoid duplication of the definitions of common entity 
types and relations. This crossing of model boundaries is 
enabled by the aforesaid IMPORT mechanism by which any 
model referred to by another is explicitly declared in the 
latter in a section immediately following the model name. 
Thus if a relation in the ER group 71 associated with entity 
type ES of FIG. 8 wishes to make an RIR reference to an 
entity of type E7 already defined in model M2, it can do so 
provided the model M2 has been declared in an "import" 
section 72 of model ML Similarly, entity type E6 of modd ^ 
Ml can use an ISA reference to inherit the relations asso- 
ciated with entity type E8 of model M3, provided model M3 
has been declared in section 72 of model Ml. 

In the example of FIG. 8, entity type E8 of model M3 is 
not only the superentiry of entity type E6 of model Ml but 35 
is also a sub-entity of entity type E9 of model M3 and, in 
addition makes an RIR reference to an entity of type E10 of 
model M4. The latter reference does, of course, require 
model M4 to be imported into model M3 by being appro- 
priately declared in section 72 of model M3. w 

It should be noted mat the 'Import* mechanism does not 
operate to provide inheritance between models; it is only 
entities that can be structured into an inheritance hierarchy. 

The core entity types (integers, characters and strings) can 
be considered to form part of a 'support* service model 45 
which is imported into every other model enabling the use 
of core entities in those models. Because these entity types 
are so widely used, no explicit import declaration is 
required, this import being assumed. 

A formal description will now be given for service models 50 
using a BNF-type language with the following notation: 
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entilyNtme 
siipcrRrs lily Nama 
3. RELATION 

Basic Ro&ticn 

relatkwiHeid 

typcinfb 

cudionlily 

CXptan&^On 

upuuu 

Note: the 'explanation' of 
to output a pseudo-natural 
DerivedRektkm 
Head 

Body 

mdExpnsskm 

^B^^.t^l I If Tlf 



:r= string 
c~ string 

Basic Relation t DerivcdRcbtttao 
'BASIC' retetiacHead 

:~ type info (rclitonNamc type info)* 

(rebrkmNnne 0 
:?= *[' ((modelNime '.' [) eatityName !) 

variable ')* 
:p= 'Q- 1 M' 

:?> •EXPLANATION' (string ! typdnfb 
option)* 

'C (string I) "* (string !) ')* 
a relation b used by (be system when it wants 
inn^ifgf! ifflii^ftf iTtari rm of s fact. 
:*» HeadTF' Body 

:— 'DERIVED' relation! lead cardinaEiy 

(explanation I) 
;:= fljcprasstoti 

: — aodExpressiaa (';' andExpresjion)* 
::= fcxpekmenr (7 expekmenQ* 

(* expression * )' : '-* expe km e nt ! 

idatkmHcad 



::= means 'is defined by*; 

« means there may bo oca or mere instances 33 

of the item concerned; 
I means OR; 

(XYZ!) means item XYZ OR no tern 



1. MODEL 
Model 
Modelbead 
Imports 
ERgroup 
Modelnaine 

2. ENTITY 
Entity 
Mode Entity 



Modelbead (Imports t) (ERgrosrp)» 
'MODEL' inodel name 
(IMPORT" model name)* 
Entity (Relation)* 
string 

CoreEntity i ModelEotiiy 
'ENTTTY* enthyNime 
('ISA* supeiEntiryNamc I) 



Structuring of Models For a substantial computer system, 
any particular system service, such as print spooling, is best 
modelled as made up of a number of internal system services 
provided to particular system objects. The structuring of the 
service models in such cases will generally reflect the 
physical world structure of the system to a greater or lesser 
extent. Consider, for example, the modelling of the printer 
spooler service illustrated in FIG. 9 in which a user 80 
(PS User) working at a machine 81 (PSClientMachine) 
wishes to print file on printer 82 (Printer) using a print server 
83 (PSServerMachiue) coupled to the machine 81 and 
printer 82 via a network 84 (Network). The first step is to 
carry out an analysis of which object is requesting what 
service from which other objects). As can be seen, the user 
80 needs the "service" SI called "canPrint[filc]on 
[prtName]", the purpose of this service being apparent from 
its name. In order for the user's machine 81 to provide this 
service SI to the user 80, it must have the following 
conditions satisfied: 

1. itself Is configured properly internally to provide the 
service; 

2. it can get the service S2 w canFmd[pSServer]Addr" 
from somewhere (to identify a print server 83 — in this case, 
the service S2 is provided by a name server 85); 

3. it can get the service S3 "hasRouteTo[pSServer] M from 
somewhere (to enable it to contact the named print server 83 
over the network); 

4. it can get the service S4 *^rmt[file]on[prtName]fxom 
[hostName]" from somewhere. 

Of the items listed above, only the last "service" is 
directly related to printing the file. 

In order that the server machine 83 is able to provide the 
service 54 ,l prfot[nle]ontprtNamc3rroro[to^ to the 

machine 81, it in turn must have the following conditions 
satisfied: 

1. itself is configured properly internally to provide the 
service; 

2. it can get the service S5 "hasRout^Tblprintcr]" from 
somewhere; 

3. it can get the service S6 "printfpsFileJ" from some- 
63 where. 

FIG. 10 shows one possible model structure for the core 
of the printer spooler service (for convenience, details of the 
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modelling of the network 84, nameservcr 85 and printer 82 requiring syntactic extraction). Secondly, a query may exer- 

have not been shown and indeed, models fox the services else a particular capability of the system which although not 

offered by these objects would generally have been done in directly supplying the required information, enables the 

advance of modelling of high level services such as the knowledge as simulator 32 to infer certain facts from the 

printer spooler service). 5 observed results. Thirdly, it is possible to write specific agent 

la the FIG. 10 model structure, the service SI provided by . P ro 8 rams running oo particular machines of the system 

the user's machine 81 (TSCuentMachine') has been ren- bdn ? mana 8 cd > to provide for these agents to provide 

dered as a service model 90 (here given the same name for s P ecific answers to particular queries. Whilst such agents 

simplicity) that includes an entity type 91 00(11(1 powerful analysis tools, the need to add to the 

('PSOicDtScrvice') corresponding to the service SI itself. 10 5Vstcm bdn 8 managed has practical drawbacks and this 

This service entity type 91 will typically have an associated approach 13 tbcrcforc not preferred, 

derived relation that sets out the conditions needing to be ^ general format of a query 100 is illustrated in 

fulfilled for the service SI to be available, these conditions simplified terms in FIG. 11. The query 100 is, of course, 

corresponding to those noted above for the user's machine aUottcd a unique name 101. Next, the action to be performed 

81 to provide the service SI. The service model 90 also is by &c managed system is specified in a command line 102 

includes an entity type 92 for the user 80 ('PSOfent') as mat constitutes the 'ccanmandspec' of the query. The 

generally there will be a condition associated with the remaining part of the query is the 'return Spec* describing 

service entity 91 that depends on the user's identity. what response can be expected to result from the action 

The service S4- provided by the print server 83 in ff te * * c command ^ 102 Md how response 

C'PSServerMachine') is rendered in the FIG. 10 model 20 rcl f tes c t0 the entities and relations of interest. The 

structure as a service model 93 that includes an entity type thc 8 / netal form of IC *P°™z 

94 ('PSServerServicc') corresponding to the service S4 J**™*'* 103 > » P** of a production named RETURN 

itself. This service entity typTwwm typically have an C ™* l * S a 10 t 4 < rcfcrred to as tlie 

associated derived relation that sets out the conditions J^fi^f^) $?t f^Jt com " 

needing to be fulfilled for the service S4 to be available, 23 Pl«^ormation ^ avauable. The Jreturnlme' 103 is then 

these conditions corresponding to those noted above in Zl^^l S C * fJ?? * ^ *!T**? ° f 

relation to the server machine 83. Further entity types 95 ('A renirnParts which are then related to entities and relations 

ServerEntity') and 96 (TSServerMachine') are ato defined ^ ^^7^ query b >g0odS ^ m 
for detailing conditions relating to configuration of the 

server machine 83. 30 an ex P hat kst of mese facts W ** generated when the 

query is compiled. 

Policies it should be noted that the conditions specified in -R^r^ ^uJnr, Q m ™. a ^ * .„ 

service models for particular service to be avaSSeTneed ^ ^1^^^^^ ° ^ ^ 

not aU be oetennined by the technical requirements of the ^"^2^ 5"? ^ 

service. Conditions may be placed on the availability of a L° * C V 0 * ,tt ^ pa ^ d ^ ^ farm of mc 

service, or ^cu^y\nC^of7J^X ^i M °* °^ W ™" W 

are determined by management policy whether local or . 

company wide. Thus, there may be a local site policy that a cai/cuvpasswa 

useXhome directory is called by the user's nameVsuch a f^* ™ ta » me ^returned line by line, each 

policy could be reSfly incorporated into a condition for „ ^^^m^^f ^ ° f * ^ 

loggingm(i.c.auser C anonlylogintome«miputersystem 40 f^^T', -^!f m ff 1 ? e 11 user 

if there is a home directory corresponding to the user's T bc # scen * 4(5 ^= « made up of the following seven 

name. Such policy conditions are preferably grouped in an clcmcnt * separated by a colon,: 

ER group associated with a Policy entity that is Squired to name-user s name on the system; 

be 'OK' for a given service to be available. Of course, it is M P^crd-user > encrypted password; 

not always clear whether a particular condition is a technical mo— user s m niraiber; 

oneorapolicyone;forexainple.apas™^ £r^'«^^ f"*^. f 

be viewed as of either rytxT info— miscellaneous items of information; 

homeDir — user's home directory 
QUERIES ^ell — user's shell 

^p« - ' goodfOT ' fac * 

£ cv^l eQa5h fi to be obtained from ^ Mi U can be seen that the 'complete- 

£3E£ ^ qU ^H S ^ 0BC 01 —SP* foD ^8 RETURN, specifies that u^uery 

more facte, and these facts are identified with the query to lcte ^ fojmatioo m % followi * ^ 

permit selection of the query appropriate for a desired fact 5J f act: snowing iypes OI 

A query works by interacting with the system being [User _J name f I 

managed and syntactically analysing the resultant response [User _J encryptedPassword [_J 

into tokens which are then related to entities and relations. [User _] userld [_] 

In the present embodiment, the interaction manager 27 is [User _J groupld ]. ] 

responsible far running thc query whilst further semantic 60 [User _J initialHomeDirPath [_] 

analysis of the response is carried out by the knowledge [User _J initialShcllPath \ 1 

assimilator 32 which is also responsible for updating the fact The syntax of each return line is given after the keyword 

base " NEW following 'line* ; the syntax follows the pattern already 

Three main types of interaction are possible. Firstly, a described with reference to FIG. 13. Considering next a 

query may use existing Mormation-providing services of 65 •returcpart*, in this case 'name', in thc example the string 

the system to directly provide the required information derived for 'name' following syntactic parsing in accordance 

{though generally packaged with other information and with the specification contained in 'line', is allotted to a 
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variable <name> and then applied to the relation "[User] 
namefname]" to produce a fact. In a similar manner facts are 
produced from the return parts 'password', *uid\ *gid\ 
tiomeDir' and 'Shell'. 



QUERY passwd 

COMMAND ::= 4 cat /etc/passwd' 

RETURN :- fine {[Us=i _l mnic Ul & [U*ec_] 

eocryptedPasiword [_J ft [User_] userld [_] 

& [Uw-J gtoupld [_] 

ft [User_J ntitiiMonieDrrPam [_1 

& mitialShcIIPath [_]}. 

line ::= (NEW [userj name':' rassword ':' vad 

';* gid *:' (info !) ':' homeDir ':' 

(shell 0 BOL) +. 
noma :;= string <name> [user] name [name]. 
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password :r= alphaNumStrinjd */^'] «5*ssword> 
[oserl eocryptedPusword [password], ■ 

vad :~ inim ^ f <uid> [on] user Id [uid}. 

gid :^ number <£kfc> [user] groupld Lgid]. 

info alphNomftriqsl'O?^-'!®** &*• 
*KKT1. 

fczmtDir :;= aIphaNumStriaf{ '//■_'] <patii> [user] 

mitialHomeDirPaih [piih]. 
shell :— »IphaNTmiStrin8['/,-_*] <pafh£> [user] 

initialSbellPath [path). 
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A more formal description of a query now follows, again 
with explanatory reference to the foregoing example query. 

A query definition is composed of the following items: 



Query::- 'QUERY' qaeryName variableDecbrations 
eommandSpec letamSpec delimitcrSpec commentSpec 
queryName is a word chosen to identify the quay. 

inmableDecbrations is used to declare die variables whose values will passed in 
at run- time for use in the eommandSpec. D efi n iti o n: 

variablcDecbrations typelnfo* 
connnandSpec is the specification of the c om marri to be executed an the 
(possibly) remote device/nuwfcine. Definition: 

cannnmdSpec ::= 'COMMAND' :.- *(soTng 1 variableNaine) + 
retumSpec defines the syntactic and semantic speaficaticc of the r etu rn value 
from ffirartfrg the commind. As can be seen from the earlier example, this part 
contains a art of BNF-type grammar productions which de fi ne the syntax of the 
return string. The very first productionName must be RETURN. Definition: 

returnSpec z= production + 

production ~ productkmName '::=* rcturnLme 
('+' I) V 

rcturnline forms the bulk of each production and is mainly comprised of the 
nanvs of other produtiaas (this allowing the hierarchical decomposition of the 
return string) and reserved words (which specify the type of a terminal symbol, 
fox example an ioteger> However, embedded within the productions are also 
some relation heads and comple tenes s infaomation. De f ii ritw n: 

returnLine :~ (retumEnclosure I prodneticoNaine ! 
newObj ( retanPart I ToEQL* J *EOL* I 
eotrmletenessPart )• 

returnHackjoire ::= *(* returriLine (T returnUney* *)' 

newQbj ::- 'NEW typeinfb 
NEW causes the creation of a new entity instance every dine it is encountered at 
run time. Thus, in the foregoing example whenever the "line" production is 
encountered while parsing an "/etc/passwd" tile, an instance of the "User" entity 
is created and assumed to the variable "user". 

returuPart relates the tokens returned from parsing to entitles and rations and 
causes facts to be produced which are added to the fact base. D efinition: 
returnPan ™ fixodRcturn I TalneRetum 
fixedRetum ::= string (oewObj I rdatkmHead I) 
value Return :?= reservedWbid (('<* TariableName *>' 0 

rdationHsad I) 
reservedWord :.- 'number' 1 'hexNumber' 
'string' (T string T 0 ' 
•alphaNumString' {'{' string '1' I) I 
•fikName' ! •printshteStrmg' 
The optkmal string in square brackets after the "string" and -abjteNumSrring" 
reserved words allows me user to add characters to the definition of these items. 
TbEGL raiTf^f the parser to skip everything from (he current point to the end of 
the line. 

EQL tells the parser to expect an end of line at this point. 
"Completeness"' as already noted refers to whether, after execu ti ng a query, there 
b total information about an item. For nrctanrf, the "/etc/passwd" tile contains 
information about ell users on the system. Thus, after executing this query the 
tact base will contain information about all known users. So, if the system is 
fl « y~H to prove that there was a user of a particular name, and me system could sot 
show that there was a user of this name, then the system can infer that there is no 
user of that name, since it knows it has information about all oxers. Definition: 

eompletenessPart '{' relatkoHead ('&' ritionHead) * *}' 
dclimiterSpec is defined as follows: 

delimiterSpec is defined as follows: 

delintitettpec ::= 'DEUMTCBR ::=* ('+* I *-') string 
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By default the query return string parser uses the space 
and tab characters to delimit tokens. However, there may be 
cases where the query writer wishes to change this set The 
foregoing example gives an instance of this; the "info" 
production needs to use the space character as a valid 
character within an infarraation string. The removal of space 
from the delimiter set causes its automatic addition to the 
alphaNumString definition. 

commcntSpec is provided to allow the query writer to 
specify the notation used for comments in the query return 
string. This allows the parser to skip these parts. Definition: 

commcntSpec :. -'COMMENT :r= 4 string TO' string 

ACTIONS 

Actions that may need to be performed in order to enable 
a particular task to be completed, are defined for each 
service model in much the same way as a query but with a 
simpler basic format: 

ACTION — action name 

COMMAND — command line 

PRE — pre conditions for action 

POST — post-conditions (ie. the effect of the action) 

INVALIDATE— variables invalidated by action 

The command line will specify a system command (far 
example, a Unix command for Unix Systems) together with 
identifiers for the items to be acted on (for example, the 
command line may contain a variable of declared type for 
specifying the machine on which the action is to be carried 
out). The preconditions specified in PRE are the conditions 
that must be true before the action can be carried out The 
post-conditions specified in POST define the effect of the 
action; it is these post-conditions that the inference engine 
will search when seeking to identify the action appropriate 
to effecting a particular task in relation to the service model 
for which the action is defined. INVALIDATE identifies the 
variables invalidated by the action, mis information being 
used to remove from me fact base any facte relying on the 
invalidated items. 

TASK PROGRAM 

As previously explained, the role of each task program 21 
(FIG. 3) is to adapt the operation of the inference engine 25 
to the task to be performed. An example diagnosis task 
program is given below in a pseudo natural language form 
for ease of understanding. 



DIAGNOSIS TASK 
WHILE do rotation fr*«vi DO 
Ibearcm Prover : icatch far solution; 
IP more infonnaiion needed THEN 
REPEAT find a query UNTIL prove pre-conditions END 

perform <juery; 
IP qocry passes THEN 

Knowledge At ti in i b tor . amimiUta query pus reasons 
ELSE 

DogDoau Task: on query future reasons 
END 
END 
END 



The above task program, which can be used in conjunc- 
tion with any service model, searches for a solution to 
whether the service concerned (as represented by an entity 
of the corresponding model) is available. This search will 
proceed through all the conditions specified in the relations 
associated with the relevant service entity until cither it is 
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proved that a required condition is not met or it is proved that 
all conditions arc met and the service is available. In 
conducting the search for a solution, queries may be used to 
ascertain facts. 

5 Considering the diagnosis task program in more detail, 
the main theorem power 33 (FIG. 4) is first called upon to 
search for a solution. If during the course of this search, the 
theorem power 33 is unable to proceed because a required 
fact is not present in the fact base 26, then the verifier 31 is 

10 used to select a query that will elicit the desired fact from the 
system. The selected query is then executed (by the inter- 
action manager 27). If the query is successfully carried out, 
the results from the query are assimilated into the fact base 
by the knowledge asstmiiator 21 and the program then loops 

15 for the theorem prover 33 to continue its search using the 
newly established facts. However, if the query fails (that is, 
is not successfully executed), then the diagnosis task is 
recursively called to establish the reason for this failure. 
If there is a problem with a service being diagnosed, the 

20 above diagnosis task program will terminate when the 
theorem prover 33 first comes across a fact proving that a 
requirement for the service to be available, has not been met 
Because the facts assimilated into the fact base are generally 
low level facts, the termination of the program at this stage 

23 will normally be . acceptable as the termination point will 
indicate the low-level fact resulting in service non- 
availability and this fact will generally be readily translat- 
able into the computer system fault (including absence of a 
resource) concerned. However, where the fact base stores 

30 high-level facts, it is desirable that the diagnosis task pro- 
gram does not terminate at a high-level fact proving service 
non-availability, but continues to decompose this fact to 
derive the underlying cause as expressed in a low-level fact 
This can be readily achieved by enclosing the above diag- 

35 nosis task program within a ' WHILE' loop of the form: 
WHILE failure explanation possible DO 
Diagnosis Task 
END 

In this case, whenever the core diagnosis task terminates 
40 on finding a fact proving service non-availability, it is asked 
to find a solution proving that fact (and ignoring its presence 
in the fact base). This process repeats until no further 
explanation is possible (as Indicated by the absence of any 
relevant query). 
45 If. in fact, the above additional WHILE loop is not limited 
to failure explanation, but is used to explain any solution, 
then the expanded diagnosis task can also be used to provide 
a full check on all conditions (high-level and low-level) 
required for a particular service. 
50 By tracking the search and using the pseudo natural 
language fact representations contained in the 'explanation* 
element of each relation, it is possible to output a listing of 
the "reasoning* followed by the theorem prover 33 in finding 
a solution. 

55 A further example of a task program is given below in 
relation to a monitoring task: 
MONITORING TASK 

WHILE Diagnosis Task: proves monitored goal true DO 
delay for monitoring interval 
60 END; 

Diagnosis Task: on whole Service 

As can be seen, the monitoring task uses the diagnosis 
task in its implementation. 

65 EXAMPLE 

Having explained in some detail the concepts of the 
present invention and how they may be implemented in one 
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embodiment a concluding and somewhat fuller example of 
a service model will now be given. The example chosen is 
that of the login service provided by a Unix workstation 
(Unix is a trademark of AT&T). 

Because of the desirability of re-using entities defined in 
other models, as well as the login service model Login, part 
of a model Unix modelling the operating system is also 
given. 

The Unix model provides the basic entities relevant when 
dealing with the Unix operating system. Here only those 
entities and relations from the Unix model which are useful 
to understand the parts of the login model are discussed 
below. 



MODEL Unix 
ENTITY User 
BASIC 

[user] irtttLalHocneDirPath [pathname], 
[user] came [userName]. 
[usti] UserH [integer], 
[user] initiilShcllPath [pathname], 
[user] groupH [integer], 
[user] enoyptcdPasswoid (string]. 
DERIVED 

[user] hasReuWriteAcceaftb [pathname] IF 

[File file] pathname [pathname], 

[user] has [lead'] accessTo [file], 

[user] has ['write'] occessTb [file). 
[usct] has [FueMode mode] accessTo [file] IF 

([file] isOwnedBy [user], 

[file] own-crModetnDode]); 

(- [file] isOwnedBy [via], 

[file] isInChoupOf [user], 

[file] grcrapMode [mode]); 

(- [file] isOwnedBy [user], 

~ [file] isIoGroupOf [user], 

[6k] woildMode [mode]): 

[us er] isSupcrUacr. 
HNTTTYFik 
BASIC 

[file] sctOrottpId. 
(file] ownaMode [flleMbdc]. 
[file) stickyBU. 
[file] name [fiJcName]. 
(file) size [integer], 
[file] worldMode [fiteMode]. 
[file] ownctld [uaedd e a ti ficrl. 
[file] date [ining]. 
[file] linksCouirt [integer], 
[file] groupModc [filcMcde]. 
[file] groupld [groupldentifler]. 
[file] ££tU«xrld. 
DERIVED 
[file] isOwnedBy [user] IF 
[file] owaerld [integer! 
[user] usedd [integer]. 
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-continued 



[login] execuubleFor [user] tQi, 
[login] raCtFdessArsOk. 



10 



1$ 



Of course, as well as these entities and relations in the 
Unix model, there are also queries one example of which 
(Query: 'passwd') has been given earlier. 

The login service model now follows: 



The foregoing derived relation for the Login entity can be 
read: 

login for a username is ok if 
there is a user with that username, and 
the user has a password (its value does not matter), and 
the user has a user ID (its value does not matter), and 
the user has a group ID (its value does not matter), and 
the user's home directory is ok, and 
the user's shell is ok. and 
the login executable files are ok for the user, and 
the login audit files are ok. 

"name", "encryptedPasswonT, "Userld" and "groupld" 
are all basic relations of the User entity (their real world 
values are obtained using the query 'passwd' described 
above). The other relations are derived ones. Here is the 
definition of one of mem, 

[login] auditFAesAreOk (M) IF 
[User root] isSuperUser, 
[r<x>t]hasReadWriteAccessTo[Pamname Vetc/utmp'], 
[rwt]hasReadWriteAccessTo[Pathname Vetc/btmp*], 
[root]hasReadWriteAccessTo[Pathname Vetc/wtmp*], 
[root]hasReadWritcAccessTo[Pathname '/etc/ 

logingroup'], 
[login] seaireTtyFUelsOk, 
[login] dMFiles AreOk. 

And here is the definition of one of the derived relations 
referenced by this: 

[login] seciireTtyFneIsOk(M)IF 
-[File _J pathname [Pathname Vetc/securetty']; 
([File _J pathname [Pathname Vetc/secuTetty'], 
[User root] isSuperUser, 

[root] hasReadAccessTo [Pathname Vetc/securetty']). 

This relation might translate as: 

The login secure try file is ok if mere is not a file/etc/ 

sccurctry, or (there is a file/etc/securetry, and 
there is a super user, and 
. the super user has read access to/etc/securetty). 

Service Verification— The following is the output from 
the system management apparatus on proving, by means of 
50 the expanded diagnosis task described above, mat login for 
the user with the name 'sijt* is 'OK'. Only the reasons for 
parts of the models detailed previously are expanded below. 
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MODEL LoginScxvioe 
IMPOST Unix 
ENTITY Login 

[login] for [userNnme] isOk (M.O) W 
[User user] name [userNamo], 
[user] cnCTyptedPassword [String_], 
[user] ujttld [UseTldemifl«_l r 
[user] groupld [Groupldentifier_] 
[user] iniriaiHnrricDirbOk. 
[user] miiialShelflsOk, 
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(login] for ('siji'JisOk is true 
because [User25'| name ('»#'] is true 

became it is proved by a query 
because ['User25'] cncryptcdPasswoid {*rX2vsS9A3<jM'] is true 
because ['U(o25'] userld [327] is true 
because ['Usci25'] groupld [15] is true 
because ['UM25*JMti2lSbeirisOk is true 
became [login] executablePor ['Vtez2S psOk is true 
because ['User^liniiialHameDirisOk is true 
because [bgtn]aadiTFi>sAreOk is true 

became ['Uwrl62'] basReadwriteAccesslb ['(etcAxmp'J is true 
because ['File397'] endPathname [Vctc/utmpl is true 
because ["Filt397 ] pattir°™ [Vetc/utmpn is true 
because ('/etcAirnip')da^'aiLc[7cfc'Jbas^«nr^njtmp'] is true 
because it b proved by a method 
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because [Dii392'J pathuaxns ['fete'] b true 
because [7clc'}(£r^"amc^•/•]bascNaIIM^[ , c^E , ] is true 

because it is proved by a method 
became [DoSO*] p^hntmr [T] b true 
became [V] equals [VJ b true 

became U is proved by a method 
because ('DirSO'Jb Root b true 
because [DirSO*] name [T] b true 

because it b proved by t query 
because fDiiSO*] canains [DirSO'l b Due 
because it b proved by a query 
because ['DitSO'] contains |'Dir392'} b true 

because it b proved by a query 
b e c au se I*Dir392'] name ['etc'] b true 
because it b proved by a query 
because [7116397'} came [*mmp'] b true 

became it b proved by a query 
because [*Dir392'l contains [T0e397'] b due 
because ii U proved by a query 
because ['Uarl62']ha3[Vritc'>ccc33Tb[Hk397'] b true 
because [*Filc397'] ovnexMode [Vrite*] b true 

because il is proved by a query 
because ['Fde397' ]lsOvnedBy ('User 162*] is true 
because ITile397'] ownerM [0] b true 

because it b proved by a query 
because [TJ*cxl62'J useild [0] b true 
because it b proved by a query 
because [*Userl621 has ['wad'] accewflb [Tik39T] is true 
because pHk397*] ownerMode ['read'J b true 

because it b proved by a query 
because ['FHc39T] bOwnedBy ['UQerl62'] b true 
because [Tik397'] owneild [0] b true 

because it b proved by a query 
because [Userl62'] userld [0] b true 
because it b proved by a query 
because [Xserl62*]bSuperUser b true 
because ('Utexl62'J userXd [0] b true 
because, h is proved by a query 
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Id the foregoing, reference to a fact being proved by a 3J 
'method' simply means that low-level code has been used to 
test a particular relation rather than using the fact base and 
query mechanism. Typically, it is convenient to cany out 
tests in this m anner for relations between core entities 
(number comparison, string matches, etc). 
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VARIANTS 



It will be appreciated that many variants are possible on 
the above-described timbodiment of the invention. Thus, for 
example, although each task has been described as being 43 
subject of a respective task program, it would be possible to 
provide other task-determined means, besides a program, for 
controlling the processing of the service models. These other 
means might include a respective dedicated inference engine 
for each task or respective hardware means for controlling a 
common general purpose processor to perform each task. 

At a more detailed level, specific measures may be taken 
to ensure as far as reasonably possible, the validity of any 
facts held in the fact base. For example, each query could be 
allocated a 'lifetime* being the time for which any facts 55 
derived by running the query can be considered valid. At the 
expiration of the query lifetime, all derivative facts (and any 
further facts based on them) are deleted from the fact base. 
With such an arrangement, monitoriag of system elements 
can be imp le m ented by using queries to derive facts on those » 
elements, with these queries having a lifetime corresponding 
to the monitoring interval; upon such a query reaching the 
end of its life, the facts of interest will be removed from the 
fact base and this can be used by the monitoring task as a 
trigger far reinitiating the corresponding query. & 

Furmermore, whilst each service model has associated 
queries and actions (where appropriate), these queries and 



actions may be shared by two or more rnodete. For example, 
a query relating to whether a file exists could well be one 
used by several different service models and it is clearly 
more efficient to share the query between models than to 
specify the query fox each model 

H will be appreciated that any suitable user interface can 
be provided for the system management apparatus; in 
particular, a graphical user interface may be used in which 
*drag and drop' actions can serve to implement tasks in 
relation to particular instances of different service models. 
We claim: 

1. A system management method of carrying out at least 
one management task in relation to at least one service 
intended to be provided by a computer system including 
cooperating physical and logical entities, said method com- 
prising the steps of: 

providing for the or each said at least one service, a 
respective declarative model specifying independently 
of any particular said task, requirements needing to be 
met for the service to be available, these requirements 
being set out in terms of the entities required and (he 
inter-relationships of the required entities, providing 
for me or each said at least one management task, 
respective task control means for controlling perfor- 
mance of the corresponding task in a manner indepen- 
dent of any particular said model and in terms of 
general inferendng operations that can be performed 
on any said model, and performing a said at least one 
management task in relation to a said at least one 
service by a process, activating the process so infer- 
endng operations are performed on the corresponding 
declarative model under the control of the said task 
control means relevant to that management task. 

2. A system management method according to claim 1, 
wherein each said task control means comprises a respective 
task program fox controlling the operation of an inference 
engine used to perform said at least one management task. 

3. A system management method according to claim 1, 
wherein each said task control means Is embodied, at least 
in part, in a respective inference engine used to perform the 
corresponding task 

4. A system management method according to claim 1, 
wherein said computer system provides multiple services In 
respect of which multiple tasks are to be effected, said 
method involving providing a respective said service model 
for each said multiple service and a respective said task 
control means for each said multiple task. 

5. A system management method according to claim 1, 
wherein said computer system is capable of supporting a 
plurality of instantiations of a said service, the said step of 
carrying out a said at least one management task in relation 
to a said at least one service, involving identifying a said 
instantiation of the service for which the task is to be carried 
out and then using the appropriate service model to infer- 
ence information in relation to the identified service instan- 
tiation. 

<>. A system management method accoriing to claim 1, 
wherein at least one said declarative model comprises a 
hierarchical structure of declarative statements inter-relating 
entities, statements lower in the hierarchy serving to detail 
requirements specified by statements higher in said hierar- 
chy. 

7. A system management method according to claim 6, 
wherein said at least one model includes, in addition to said 
statements specifying requirement statements generally 
inter-relating said entities and usable to infer whether a 
particular said requirement has been met. 
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8. A system management method accor ding to claim 6, 
wherein a plurality of said service models are provided cadi 
specifying a respective said service, at least two said models 
being associated such that statements set out in one said 
model and involving a particular said entity are usable in 
another model that also refers to that entity. 

9. A system management method according to claim 1, 
wherein said requirements comprise both a set of essential 
technical requirements and a further set of operational policy 



16. A system management method according to claim 15, 
wherein said management task being carried out is an 
installation of said service, 

17. A system management method according to daim 1 
wherein said computer system comprises a network of 
computers. 

18. System management apparatus for carrying out at 
least one management task in relation to at least one service 
intended to be provided by a computer system including 



technical requirements and a further set ot operational policy r ^ hysical md logical entities, said apparatus 
requirements, these sets being specified separately from 10 v 3 
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each other. 

10. A system management method according to claim 1, 
wherein said step of carrying out a said at least one man- 
agement task involves interacting with said system to ascer- 
tain cither directly or through inferencing from the results of 
the interaction, whether a said requirement relevant to the 
service concerned is met by the system. 

11. a system management method according to claim 1, 
wherein said method further comprises the step of providing 

a fact base holding facts on the status of the system, said step 20 
of carrying out a said at least one management task involv- 
ing referring to said fact base to ascertain whether a said 
requirement relevant to the service concerned can be per- 
formed by the system in the status it has. 

12. A system management method according to claim 1, 25 
wherein said method further comprises the step of providing 

a fact base holding facts on the status of the system, said step 
of carrying out a said at least one management taskincluding 
ascertaining whether a said requirement relevant to the 
service concerned is met by the system by referring to said 3D 
fact base for facts relevant to said requirement, and in the 
event that insufficient facts about the status of the system are 
present in the fact base to ascertain whether said requirement 



comprising: 

a declarative model specifying independently of any 
particular said task, the requirements needing to be met 
for the service to be available, these requirements being 
set out in terms of the entities required and the inter- 
relationships of the required entities, one of said 
declarative models being provided for the or each said 
at least one service, 
inference engine means for carrying out inferencing 

operations in relation to a said declarative model, 
task control means, one of said task control means being 
respectively provided far the or each said at least one 
management task, each task control means being 
arranged for controlling performance of the corre- 
sponding task by said inference engine means in a 
mppnrr independent of any particular said model and in 
terms of general inferencing operations, and 
means for causing a said at least one management task to 
be carried out in relation to a said at least one service, 
said means for causing being arranged far causing said 
inference engine means to operate on the corresponding 
declarative model under the control of the said task 
control means relevant to that management task. 
19. System management apparatus according to claim 18, 



is met, interacting with the system to ascertain cither directly , o ^ « 

or through inferencing from the results of this interaction the 35 said apparatus further comprising fact base means storing 

further needed facts about the status of the system. facts about the status of said system, and interaction means 

13 A system management method according to claim 12. for interacting with said system to ascertain either directly or 
wherein the results derived from interacting with the system through inferencing from the results of the interaction, facts 
are stored in said fact base. about the status of the system, said inference engine means 

14 A system management method according to claim 1, 40 being operative in the course of carrying out a said man- 
wherein said management task being carried out is a fault agement task for (a) checking whether a said requirement is 
diagnosis task. ^ing met by said system by referring to said fact base 

15. A system management method according to daim 1 means and (b) causing said interaction means to interact 
wherein said step of carrying out a said management task with the system to elicit further facts in the event that 
involves changing said system to meet a said requirement of 45 insufficient facts about the status of the system are present in 
the service concerned, the changing step being performed by the fad base means, 
adding ox removing an entity or by modifying the inter- 
relationship between at least two said entities. * * * * * 
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